System and method for event detection and re-direction over a network using a presentation level protocol

ABSTRACT

A mechanism for detecting events generated from a device in communication with a client system and the re-direction of those events to a server system over a network using a presentation-level protocol is disclosed. Plug and play events are detected at the client system, bound to a virtual connection for a user session, and re-directed for handling to a server-based system using the presentation-level protocol. The server-based system maps the device to the user session. Applications which have registered a callback with the session are informed and generate an appropriate message which is transmitted to the device in communication with the client system via a specified virtual communication connection in the user session.

RELATED APPLICATIONS

This patent application claims priority to U.S. Pat. No. 7,702,750,filed on Sep. 29, 2004, the disclosure of which is considered part ofthe disclosure of this application and is herein incorporated byreference in its entirety.

FIELD OF THE INVENTION

The illustrative embodiment of the present invention relates generallyto event detection at a client system, and more specifically to there-direction to a server system of Plug and Play events generated by adevice communicating with a client system.

BACKGROUND OF THE INVENTION

Plug and Play (PnP) is a combination of hardware and software supportthat enables a computer system to recognize and adapt to hardwareconfiguration changes in devices/components interfaced with the systemwith little or no user intervention. With Plug and Play, a user can addor remove devices dynamically, without manual configuration and withoutany intricate knowledge of computer hardware. For example, a user candock a PDA or laptop and use the docking station's Ethernet card toconnect to a network without changing the configuration settings for theconnected device. Subsequently, the user can undock the same PDA orlaptop and use a modem to connect to the network without having to makeany manual configuration changes.

Plug and play events for devices connected to a computer are typicallyhandled by the operating system of the system with which the device iscommunicating. For example, a PDA tethered to a PC would have its eventshandled by the PC OS. The system is able to automatically load andunload device drivers to reflect the different devices attached to thesystem when they are docked or undocked. Also, applications are able toautomatically adjust their configurations to reflect the insertion orremoval of devices, e.g., PDAs. Plug and Play allows a user to change acomputer's configuration with the assurance that all devices will worktogether and that the machine will boot correctly after the changes aremade.

Unfortunately, the conventional method of handling Plug and Play events(such as “device arrival” and “device removal”) does not workparticularly well where the new device is communicating with a clientsystem connected to a server in a server-based computing system. Theclient system in a server-based computing system is frequently incontact with the server system over a network via a presentation levelprotocol supporting a user session executing on the server. The serversystem deploys, manages, supports and executes applications on theservers thereby relieving the client system of the need to host andexecute the applications. The server deploys a presentation levelprotocol and architecture such as the Independent Computing Architecture(ICA) from Citrix Systems Inc. of Fort Lauderdale, Fla., the RemoteDesktop Protocol (RDP) from Microsoft Corporation of Redmond, Wash. andthe X-Window Protocol from the X-Open Consortium. A user connected tothe client system who wishes to execute an application or accessresources on the server is connected in a dedicated session to theserver. Conventionally however, the Plug and Play manager for theoperating system of the client system handles any messages generated bydevices connecting to, or removing from, the client system and thegenerated events do not impact the existing user session.

BRIEF SUMMARY OF THE INVENTION

The illustrative embodiment of the present invention provides amechanism for detecting events generated from a device in communicationwith a client system and re-directing those events to a server systemover a network using a presentation-level protocol. Plug and play eventsare detected at the client system, bound to a virtual connection for auser session, and re-directed for handling to a server-based systemusing the presentation-level protocol. The server-based system maps thedevice in the user session. Applications which have registered acallback with the session are informed and generate an appropriatemessage which is transmitted to the device in communication with theclient system via a specified virtual communication connection in theuser session.

In an embodiment, a method for handling plug and play events occurringat a client provides a client communicating with a server over a networkusing a presentation-level protocol. The method also detects a plug andplay event notification regarding a device in communication with theclient. The method redirects the event notification to a server. Themethod then receives from the server a command directed to the device.

In another embodiment, a method for handling plug and play eventsoccurring at a client communicating with a server using apresentation-level protocol includes the step of receiving from a clienta plug and play notification regarding a device in communication withthe client.

The method also notifies an application program hosted by the server ofthe occurrence of the event notification. The method further includesthe step of receiving from the application program hosted by the servera command directed to the device. The command directed to the device isthen transmitted to the client.

In one embodiment, for handling events occurring at a client incommunication with a server using a presentation-level protocol includesthe step of receiving from a client an event notification regarding adevice in communication with the client. The method also notifies anapplication program hosted by the server of the occurrence of the eventnotification. The method further includes the step of receiving from theapplication program hosted by the server a command directed to thedevice. The command directed to the device is then transmitted to theclient.

In a different embodiment, a method for informing a server about thepresence of devices connected to a client communicating with the serverusing a presentation-level protocol includes the step of emulating aplug and play event notification regarding a device in communicationwith the client. The method also includes the step of redirecting theemulated event notification to a server. The method further includes thestep of receiving from the server a command directed to the device incommunication with the client.

In one embodiment, a method for enumerating devices communicating with aclient that have been mapped into a session on a server includes thesteps of launching an application in a user session on a server. Themethod also includes the steps of intercepting device enumerationmethods in the server-based user session and redirecting the deviceenumeration methods to a control virtual driver on the server. Themethod also emulates an arrival event for at least one device enumeratedby the redirected method. The device for which the arrival event isemulated is a device in communication with a client system that wasmapped into the user session prior to said application launch. Themethod also notifies the application hosted by the server that an eventnotification has been occurred.

In another embodiment, a method for handling plug-and-play eventsoccurring at a client includes the step of detecting a plug-and-playevent notification regarding a device communicating with the client viaa USB connection. The method further redirects the event notification toa server over a network. Subsequent to the redirection of the eventnotification to the server, the method includes the step of receiving acommand directed to the device from the server.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects of this invention will be readily apparent fromthe detailed description below and the appended drawings, which aremeant to illustrate and not to limit the invention, and in which:

FIG. 1A is a block diagram of an embodiment of an environment suitablefor practicing the illustrative embodiment of the present invention;

FIG. 1B is a block diagram depicting the environment of FIG. 1A in moredetail;

FIGS. 2A and 2B are block diagrams depicting embodiments of computersuseful in connection with the present invention;

FIG. 3 is a flowchart of one embodiment of the sequence of stepsfollowed by the present invention to re-direct device generated eventsdetected at a client system to a server system using a presentationlevel protocol;

FIG. 4 is a flowchart of one embodiment of the sequence of stepsfollowed by a server in the present invention to handle the eventsdetected in FIG. 3;

FIG. 5 is a flowchart of one embodiment of the sequence of stepsfollowed by the present invention to map a virtual device to a usersession;

FIG. 6 is a flowchart of one embodiment of the sequence of stepsfollowed by the present invention to send a command from an applicationinstance executing within a session to a virtual device communicatingwith a client system that has been mapped to the user session;

FIG. 7 is a flowchart of one embodiment of the sequence of stepsfollowed by the present invention to emulate and re-direct devicegenerated events at a client system to a server system using apresentation level protocol;

FIG. 8 is a flowchart of the sequence of steps followed by an embodimentof the present invention to synchronize a collection of data on a devicein communication with a client system with a collection of data on aserver within an existing user session;

FIG. 9A is a block diagram of an embodiment of the present inventiondepicting the use of a proxy client in a pass-through environment;

FIG. 9B is a block diagram of another embodiment of the presentinvention depicting the use of a proxy client in a pass-throughenvironment where the proxy client is located on the server hosting theuser session; and

FIG. 9C depicts a block diagram of an embodiment of the presentinvention implemented without the use of a presentation-level protocolsupporting architecture.

DETAILED DESCRIPTION OF THE INVENTION

The illustrative embodiment of the present invention detects plug andplay events generated by devices in communication with a client systemto be redirected to an existing session on a server for handling. Thedevice generating the event is mapped to the existing user session.Applications which have registered a callback with the session areinformed and generate a message based on the type of event. The messageis transmitted to the device in communication with the client system viaa specified virtual communication connection in the user session.

FIG. 1A depicts an environment suitable for practicing an embodiment ofthe present invention. A user 2 has access to a client system 4. Theclient system 4 includes a presentation-level protocol supportingarchitecture 6 such as ICA, RDP or X-Open Windows. Thepresentation-level protocol supporting architecture 6 is used toestablish a connection over a network 10 with a presentation-levelsupporting architecture 14 included on a server 12. Thepresentation-level protocol supporting architecture 14 establishes usersessions, session I (16), session II (18) and session III (20). Requestsfrom a user 2 are mapped into the appropriate session. Those skilled inthe art will recognize that a single user may establish multiplesessions. Alternatively, multiple users may establish individualsessions 16, 18 and 20 on the server 12. Each session 16, 18 and 20 mayinclude instances of one or more applications 22 and 24 available tohandle client system 4 requests. A device 24 in communication with theclient system 4 may generate an event 26 which is intercepted andredirected to a session 16, 18 and 20 for handling. The device 24 incommunication with the client system 4 may take many forms. The device24 may be a printer, scanner, digital camera, mobile phone, PDA, orother device exporting a serial communication interface capable ofcommunicating with the client system 4.

Portions of the environment depicted in FIG. 1A are shown in more detailin FIG. 1B. An exemplary Presentation Level Protocol SupportingArchitecture 6 on the client side includes an engine 30 and ProtocolStack 32. The Protocol Stack 32 includes a Protocol Driver (PD), andTransport Driver (TD). The Presentation Level Protocol SupportingArchitecture 6 also includes an OS Abstraction Layer 31, a Plug and PlayManager 34, a USB driver stack 36 and an I/O manager 38. ThePresentation Level Protocol Supporting Architecture 6 further includes acontrol virtual driver (CTL VD) 40, used to transmit control informationover a virtual control connection 44 to and from the server 12, and aRedirector virtual driver/Client COM Mapping Virtual Driver (CCM VD) 42which is used to transmit data over a virtual communication connection48 to and from a server 12. The CTL VD 40 registers a callback forcertain events with the OS abstraction layer 31. The callback is astanding request left with the OS abstraction layer 31 by the CTL VD 40to execute a particular instruction (such as notifying the CTL VD) inthe case of the occurrence of a specified event. The OS abstractionlayer 31 intercepts events generated by the PNP Manager 34 such asdevice arrival events generated by a printer 60 connecting to USB driverstack 36. The callback to the CTL VD 40 that is executed sendsinformation to the server about the printer 60 and the event as setforth below in more detail.

Although FIG. 1B depicts a printer 60 communicating with the client-sidePresentation Level Protocol Supporting Architecture 6 via a USB driverstack 36, it should be understood that many other implementations arepossible within the scope of the present invention. For example thedevice 24 communicating with the client system 4 may be any deviceexporting a serial interface. Accordingly, the device 24 communicatingwith the client system 4 may communicate using an IR serial protocol, aBluetooth serial protocol, the IEEE 1394 protocol, FIREWIRE, the WI-FIprotocol, the USB protocol, or other wireless protocol as long as theclient system 4 supports communications with the device 24 using theparticular protocol.

The server 12 includes the server-side of the presentation levelprotocol supporting architecture 14 depicted in FIG. 1B. The server-sideof the presentation level protocol supporting architecture 14 supportsmultiple user sessions 16, 18 and 20. The depicted user session I (16)includes a server-side CTL VD 46 used to establish a virtual channel 44with the client-side CTLVD 40 in order to transmit control informationbetween the client system and the server.

Session I (16) also includes one or more applications 22 and 24 such asthe depicted instance of the application 22 which may act as a resourcefor the printer 60. Separate instances of application 22 run as separateprocesses within each user session. Alternatively, the application 22may be a synchronizing application, such as ACTIVESYNC from MicrosoftCorporation, or HOTSYNC from PalmOne, Inc. of Milpitas, Calif. Thoseskilled in the art will recognize that Session I (16) may include manydifferent types of applications in addition to/in place ofsynchronization applications without departing from the scope of thepresent invention.

Session I (16) also includes a Network Provider module 52 which makes anRPC call to a driver mapping service as part of the process of mappingvirtual devices into a user session. The mapping process is discussed inmore detail below. The Network Provider module 52 is in contact with thedriver mapping service 56, which communicates with the Object Manager58. The Driver Mapping Service 56 and the Object Manager 58 are alsopart of the Presentation-Level Protocol Supporting Architecture 14 butlocated outside the session 16. The application 22 communicates with theI/O Manager 54. The I/O Manager 54 communicates with the Object Manager58 and the Device Redirector 50. The Device Redirector 50 is used toform a virtual communication channel 48 with the client-side CCM VD 42for transmitting data. Also included in the Presentation Level ProtocolSupporting Architecture 14 is a server-side Protocol Stack 60 includinga PD and TD. The operations of the server-side components depicted inFIG. 1B are discussed in more detail below.

Those skilled in the art will recognize that the actual components inthe Presentation Level Protocol Supporting Architectures 6 and 14 willvary depending upon the architecture deployed. In the ICA architecturethe protocol stacks 32 and 60 are ICA stacks. The OS Abstraction Layer31 is a WINDOWS Abstraction Layer. Similarly, the Object Manager 58 is aWINDOWS Object Manager, the client-side Presentation Level ProtocolSupporting Architecture 6 is an ICA client, and the server-sidePresentation Level Protocol Supporting Architecture 14 is a METAFRAMEPRESENTATION SERVER in an ICA architecture. It will also be recognizedthat the components of an RDP architecture, X-Open architecture or otherpresentation level protocol supporting architecture may vary from thecomponents depicted herein without departing from the scope of thepresent invention.

In many embodiments, the client system 4 and server 12 are provided aspersonal computer or computer servers, of the sort manufactured by theHewlett-Packard Corporation of Palo Alto, Calif. or the Dell Corporationof Round Rock, Tex. FIGS. 2A and 2B depict block diagrams of a typicalcomputer 200 useful as the client system 4 and server 12. As shown inFIGS. 2A and 2B, each computer 200 includes a central processing unit202, and a main memory unit 204. Each computer 200 may also includeother optional elements, such as one or more input/output devices 230a-230 n (generally referred to using reference numeral 230), and a cachememory 240 in communication with the central processing unit 202.

The central processing unit 202 is any logic circuitry that responds toand processes instructions fetched from the main memory unit 204. Inmany embodiments, the central processing unit is provided by amicroprocessor unit, such as: the 8088, the 80286, the 80386, the 80486,the Pentium, Pentium Pro, the Pentium II, the Celeron, or the Xeonprocessor, all of which are manufactured by Intel Corporation ofMountain View, Calif.; the 68000, the 68010, the 68020, the 68030, the68040, the PowerPC 601, the PowerPC604, the PowerPC604e, the MPC603e,the MPC603ei, the MPC603ev, the MPC603r, the MPC603p, the MPC740, theMPC745, the MPC750, the MPC755, the MPC7400, the MPC7410, the MPC7441,the MPC7445, the MPC7447, the MPC7450, the MPC7451, the MPC7455, theMPC7457 processor, all of which are manufactured by Motorola Corporationof Schaumburg, Ill.; the Crusoe TM5800, the Crusoe TM5600, the CrusoeTM5500, the Crusoe TM5400, the Efficeon TM8600, the Efficeon TM8300, orthe Efficeon TM8620 processor, manufactured by Transmeta Corporation ofSanta Clara, Calif.; the RS/6000 processor, the RS64, the RS 64 II, theP2SC, the POWER3, the RS64 III, the POWER3-II, the RS 64 IV, the POWER4,the POWER4+, the POWER5, or the POWER6 processor, all of which aremanufactured by International Business Machines of White Plains, N.Y.;or the AMD Opteron, the AMD Athalon 64 FX, the AMD Athalon, or the AMDDuron processor, manufactured by Advanced Micro Devices of Sunnyvale,Calif.

Main memory unit 204 may be one or more memory chips capable of storingdata and allowing any storage location to be directly accessed by themicroprocessor 202, such as Static random access memory (SRAM), BurstSRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM),Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended DataOutput RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), BurstExtended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM),synchronous DRAM (SDRAM), JEDEC SRAM, PC100 SDRAM, Double Data RateSDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM),Direct Rambus DRAM (DRDRAM), or Ferroelectric RAM (FRAM).

In the embodiment shown in FIG. 2A, the processor 202 communicates withmain memory 204 via a system bus 220 (described in more detail below).FIG. 2B depicts an embodiment of a computer system 200 in which theprocessor communicates directly with main memory 204 via a memory port.For example, in FIG. 2B the main memory 204 may be DRDRAM.

FIGS. 2A and 2B depict embodiments in which the main processor 202communicates directly with cache memory 240 via a secondary bus,sometimes referred to as a “backside” bus. In other embodiments, themain processor 202 communicates with cache memory 240 using the systembus 220. Cache memory 240 typically has a faster response time than mainmemory 204 and is typically provided by SRAM, BSRAM, or EDRAM.

In the embodiment shown in FIG. 2A, the processor 202 communicates withvarious I/O devices 230 via a local system bus 220. Various buses may beused to connect the central processing unit 202 to the I/O devices 230,including a VESA VL bus, an ISA bus, an EISA bus, a MicroChannelArchitecture (MCA) bus, a PCI bus, a PCI-X bus, a PCI-Express bus, or aNuBus. For embodiments in which the I/O device is a video display, theprocessor 202 may use an Advanced Graphics Port (AGP) to communicatewith the display. FIG. 2B depicts an embodiment of a computer system 200in which the main processor 202 communicates directly with I/O device230 b via HyperTransport, Rapid I/O, or InfiniBand. FIG. 2B also depictsan embodiment in which local busses and direct communication are mixed:the processor 202 communicates with I/O device 230 a using a localinterconnect bus while communicating with I/O device 230 b directly.

A wide variety of I/O devices 230 may be present in the computer system200. Input devices include keyboards, mice, trackpads, trackballs,microphones, and drawing tablets. Output devices include video displays,speakers, inkjet printers, laser printers, and dye-sublimation printers.An I/O device may also provide mass storage for the computer system 200such as a hard disk drive, a floppy disk drive for receiving floppydisks such as 3.5-inch, 5.25-inch disks or ZIP disks, a CD-ROM drive, aCD-R/RW drive, a DVD-ROM drive, tape drives of various formats, and USBstorage devices such as the USB Flash Drive line of devices manufacturedby Twintech Industry, Inc. of Los Alamitos, Calif.

In further embodiments, an I/O device 230 may be a bridge between thesystem bus 220 and an external communication bus, such as a USB bus, anApple Desktop Bus, an RS-232 serial connection, a SCSI bus, a FireWirebus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a GigabitEthernet bus, an Asynchronous Transfer Mode bus, a HIPPI bus, a SuperHIPPI bus, a SerialPlus bus, a SCI/LAMP bus, a FibreChannel bus, or aSerial Attached small computer system interface bus.

General-purpose desktop computers of the sort depicted in FIGS. 2A and2B typically operate under the control of operating systems, whichcontrol scheduling of tasks and access to system resources. Typicaloperating systems include: MICROSOFT WINDOWS, manufactured by MicrosoftCorp. of Redmond, Wash.; MacOS, manufactured by Apple Computer ofCupertino, Calif.; OS/2, manufactured by International Business Machinesof Armonk, N.Y.; and Linux, a freely-available operating systemdistributed by Caldera Corp. of Salt Lake City, Utah, among others.

For embodiments in which the device in communication with the clientsystem 24 is a mobile device, the client device may be a JAVA-enabledcellular telephone, such as the i50sx, i55sr, i58sr, i85s, i88s, i90c,i95cl, or the im11000, all of which are manufactured by Motorola Corp.of Schaumburg, Ill., the 6035 or the 7135, manufactured by Kyocera ofKyoto, Japan, or the i300 or i330, manufactured by Samsung ElectronicsCo., Ltd., of Seoul, Korea. In other embodiments in which the device 24in communication with the client system is mobile, it may be a personaldigital assistant (PDA) operating under control of the PalmOS operatingsystem, such as the Tungsten W, the VII, the VIIx, the i705, all ofwhich are manufactured by palmOne, Inc. of Milpitas, Calif. In furtherembodiments, the device 24 in communication with the client system 4 maybe a personal digital assistant (PDA) operating under control of thePocketPC operating system, such as the iPAQ 4155, iPAQ 5555, iPAQ 1945,iPAQ 2215, and iPAQ 4255, all of which manufactured by Hewlett-PackardCorporation of Palo Alto, Calif., the ViewSonic V36, manufactured byViewSonic of Walnut, Calif., or the Toshiba PocketPC e405, manufacturedby Toshiba America, Inc. of New York, N.Y. In still other embodimentsthe device in communication with the client system 24 is a combinationPDA/telephone device such as the Treo 180, Treo 270 or Treo 600, all ofwhich are manufactured by palmOne, Inc. of Milpitas, Calif. In still afurther embodiment, the device in communication with the client system24 is a cellular telephone that operates under control of the PocketPCoperating system, such as the MPx200, manufactured by Motorola Corp.

As previously mentioned, the illustrative embodiment of the presentinvention re-directs to a server 12 plug and play events and other typesof events such as emulated plug and play events generated about thedevice in communication with the client system 24. The events areredirected over a network 10 using a presentation level protocol. FIG. 3is a flowchart of the client-side sequence of steps followed by anembodiment of the present invention to redirect to an existing usersession on a server a detected event caused by a device 24 incommunication with the client system 4. Although, the descriptioncontained herein discusses the re-direction of detected plug and playevents (and emulated fake plug and play events) it should be understoodthat other types of events may also redirected without departing fromthe scope of the present invention.

The client-side sequence of steps in FIG. 3 begins with the Control VD40 registering a callback to be notified of certain events with the OSabstraction layer 31 (step 300). The callback may specify that theControl VD 40 is only interested in certain device classes that generatean event. Alternatively, the callback registration may request that theControl VD 40 be notified only in the case of a particular type of event(e.g.: device arrival and removal). Similarly, the Control VD 40 mayrequest that it be notified only of events that are generated by devicesconnected to a particular port (e.g.: only notify for devices connectedto a USB port). Those skilled in the art will recognize that additionalor other parameters may be specified in the callback registration. Whena device in communication with the client system is docked at a USB port(step 302), the PNP manager 34 issues a device arrival event (step 304)which is intercepted by the OS abstraction layer 31. The eventnotification includes information such as a GUID for the device (aglobally unique ID), a vendor ID, a product ID, the type of event and adevice name. Upon intercepting the event notification, the OSabstraction layer 31 determines if a registration exists for thedetected event, and, if so, executes a callback to the Control VD 40informing the Control VD of the occurrence of the event for which itregistered. The callback passes the event information to the Control VD(step 306).

Upon receiving the callback, the Control VD 40 queries a table toidentify a redirector VD (CCM VD 42) and sends a Bind request to theredirector VD (CCM VD) (step 308). The CCM VD 42 provides a logical COMport number for the Virtual Communication Channel (referred to as a COMcontext or virtual context herein) and binds it to the event informationindicated in the request (GUID, Vendor ID, Product ID, Device Name,etc.). The bound request is returned to the Control VD 40 (step 310).The binding (the event information plus the COM context for the VirtualCommunication Channel 48) is then sent to the server 12 (step 312). TheControl VD 40 receives response from the server 12 indicating thesuccess or failure of the mapping of the virtual device in therespective session (step 314). Upon failure, the Control VD 40 notifiesthe CCM VD 42 to unbind the virtual context. In the event of asuccessful mapping operation, subsequently, the CCM VD 42 receives acommand from an Application 22 running in a user session 16, 18 and 20on the server 12 that is addressed to the Redirector VD/CCM VD 42 at thevirtual context. For example, the command may be a command to open thereferenced virtual COM port assigned in the binding process (the virtualCOM number represented by the COM context) to the device incommunication with the client system Once the virtual COM port has beenopened, subsequent I/O requests for the device in communication with theclient system are received on the virtual COM port referenced in thebinding (step 316).

FIG. 4 is a flowchart of one embodiment of the sequence of stepsfollowed by a server in the present invention to handle the eventsdetected in FIG. 3. The sequence begins when the Control VD 46 on theserver 12 receives the bound PNP event notification (step 320). TheControl VD then requests the device in communication with the clientsystem be mapped into the session. (step 322). The details of themapping request are discussed further in reference to FIG. 5 below. Ifthe mapping request fails (step 321), a failure message is transmittedback to the CCM VD 42 so that the device can be unbound (step 322). Ifthe mapping request succeeds (step 321), the CTL VD 46 broadcasts thePNP event within the current session (step 324). In another embodiment,the PnP device registration API is intercepted on the server 12, andonly apps that have registered for PnP events are notified. Anapplication 22 within the session receives the PNP broadcast event (step326) and sends an Open command to the server OS referencing the virtualdevice bound into the event notification (step 328). The server OS, withthe help of the I/O Manager 54 and Object Manager 58, and based on thesyntax of the symbolic link established in the mapping (step 322),redirects it to the Device Redirector 50 (step 328), which in turnredirects it to the corresponding session and I/O Redirector VD, againbased on the syntax of the symbolic link (step 330). The steps taken bythe application 22 to send a command to the device in communication withthe client system are discussed further in FIG. 6 below. The command maybe an “Open” command and be directed to the particular COM communicationport. The command is forwarded to the I/O Redirector VD (CCM VD) 42 onthe client side for further processing where execution of the commandwill be attempted.

The mapping process engaged in by the server-side presentation-levelprotocol supporting architecture 14 is now discussed in further detail.FIG. 5 depicts the sequence of steps followed by an embodiment of thepresent invention to map the received event notification to a virtualdevice in an existing user session. The sequence begins following theserver side Control VD 46 receiving the bound PNP event notification andrequesting mapping of the virtual device into the user session (step 320of FIG. 4). The CTL VD 46 generates unique names for the server andremote client using the information in the event notification (Step338). The unique name for the server may be based on the informationreceived in the event notification, the GUID, virtual context, orcontext ID. The unique name for the remote client may be based on thevirtual context (VD name and context). The CTL VD 46 loads the drivermapping network provider module 52 and provides the unique names (step340). The network provider module 52 places an RPC call to the drivermapping service module 56 (step 342). The driver mapping service 56generates a path for the virtual device and requests the Object Manager58 create a symbolic link to the virtual device in the user session 16using the name information (step 344). The symbolic link is entered intoan internal table in the session (step 346). The I/O Manager 54 willlater use the first part of the symbolic link information to performredirection. The server-side Control VD 46 then broadcasts a PNPnotification within the session which includes the symbolic link to thevirtual device (step 324 of FIG. 4). Those skilled in the art willrecognize that although a broadcast by the Control VD of the eventnotification has been discussed above, a callback registration processby which applications register within the session to be notified of theoccurrence of a specified event may also be employed without departingfrom the scope of the present invention. In such a case, only thoseapplications within the session that previously requested notificationof the occurrence of the specified event would be notified following themapping of the virtual device within the session.

After the device in communication with the client system has been mappedinto the user session 16 and the event notification broadcast within thesession, applications running within the session are able to respond tothe event. FIG. 6 is a flowchart depicting the sequence of stepsfollowed by an embodiment of the present invention to respond to anevent notification. Upon receiving the PNP event notification, theapplication 22 attempts to open a local device name of the device sothat commands and data may be sent to the device. The sequence beginswith the Application 22 sending an Open command to a local I/O manager54 (step 360). The I/O manager 54 sends a name resolution request to theObject Manager 58 (step 362). The Object Manager 58 returns aredirection path to the I/O manager 54 (step 364) which forwards theOpen command and the redirection path to the Device Redirector 50 (step366). The Device Redirector 50 resolves the path to a particular sessionand an I/O Redirection VD 50 (CCM VD) (step 368). The Device Redirector50 then transmits a command to the CCM VD 42 for execution (step 370).For example, the application may transmit an “open” request for virtualCOM port 3, which will be transmitted to the client side I/O RedirectorVD (CCM VD 42) for execution. The client CCM VD 42 will apply the Opencommand to the actual device bound to the virtual COM port. Once thevirtual COM port is open, it will be used to transmit data between theserver side application 22 and the device in communication with theclient system 24 over the virtual communication channel 48. It should beunderstood that other commands other than “open” may be sent withoutdeparting from the scope of the present invention.

Device removal works similarly to device addition. The detected removalevent is sent with a release device request to the Redirector VD 42. TheRedirector VD 42 binds the COM context to the notification. The boundevent is sent to the server where it is parsed. At the server, thevirtual device instance is unmapped from the user session 16. The MPSsends a release command back to the CTL VD on the client system. The CTLVD forwards the release command to the CCM VD which releases theassigned COM context, and records the COM port availability.

In addition to detecting PNP events from a device 24 communicating withthe client system 4, the illustrative embodiment of the presentinvention also enables devices previously connected to be mapped into auser session by emulating a plug and play event and then handling theemulated event as outlined above. FIG. 7 depicts the sequence of stepsfollowed by an embodiment of the present invention to emulate a plug andplay event for a previously connected device in order to map the deviceinto the existing user session. The sequence begins with thedetermination of devices in communication with the client system (step380). This may be determined by the client system operating systemenumerating the communicating devices. For each device, the clientsystem then emulates an event (step 382). The context ID is bound toeach event (step 384) as outlined above and the emulated eventinformation, including the bound context ID is sent to the server overthe control communication channel (step 386). Subsequently following themapping of the device into the user session, the client system mayreceive a command from an application instance running in the usersession directed to the virtual driver for the device (step 388).

The illustrative embodiment of the present invention also enables thesynchronizing of a collection of data on the device in communicationwith the client system with a collection of data on the server. Forexample, the data in a user's OUTLOOK (from Microsoft Corporation)application on a PDA may be synchronized with a user's OUTLOOK data on aserver using a synchronizing application executing within a user sessionrather than synchronizing the OUTLOOK application with data from theclient system to which the PDA is communicating.

FIG. 8 depicts the sequence of steps followed by an embodiment of thepresent invention to synchronize a collection of data on a device incommunication with a client system with a collection of data on a serverwithin an existing user session. The sequence begins with thenotification of the presence of a device in communication with a clientsystem being bound to a virtual context at the client system asdiscussed above (step 400). The binding is then sent to the server (step402) where the device is mapped to a user session (step 404). Aninstance of a synchronizing application which is executing in the usersession is then selected by a user. The synchronizing application may beACTIVESYNC from Microsoft Corporation, HOTSYNC from PalmOne or anothertype of synchronizing application. The synchronizing application thencompares a specified collection of data on the device 24 incommunication with the client system 4 with a collection of dataaccessible from the user session (step 408). For example, ACTIVESYNC maybe used to synchronize a calendar in OUTLOOK on the device 24 incommunication with the client system 4 with the calendar in an instanceof OUTLOOK on a user desktop within the session. Once the collections ofdata have been compared, they are synchronized by the application (step410).

ActiveSync is the standard Microsoft application that providessynchronization and device management for a WinCE-based PDA device(PocketPC).

ActiveSync is both session (multi-user) unaware and multi-host(multi-computer) unaware. ActiveSync processes use windows sockets forinter-process communication (IPC) between themselves, and otherprocesses, e.g., explorer.exe, outlook.exe. Sockets are used even forcommunication between different threads of an ActiveSync process. Acombination of local host loop-back address (127.0.0.1), and all(0.0.0.0, i.e., INADDR_ANY) are used. In addition, ActiveSync alwaysruns on the console, as even if removed from the startup sequence,ActiveSync recreates itself in the startup the next time it is launched.Without hooking, when ActiveSync runs in multiple user sessions, socketconnections collide. Even if a single ActiveSync instance is run in aremote session, collision with the local console session's ActiveSyncinstance occurs. Accordingly, the illustrative embodiment of the presentinvention hooks socket calls to avoid collisions.

Windows socket communications of ActiveSync processes and explorer.exe(in communication with ActiveSync processes only), are hooked by thepresent invention to avoid collisions. In session, special virtual IPaddress hooking and virtual loop-back address hooking are performed. TheVirtual loop-back address hooking adds the session ID to the local-hostloop-back address (127.0.0.1) represented as a ULONG. Virtual loop-backaddresses are and have to be unique with only one address per server.Virtual loop-back addresses are also used as Virtual IP addresses.Virtual IP address hooking is performed only for non-zero ports, i.e.,for local communications of ActiveSync. Socket communications are alsohooked on the console.

Examples of the hooking performed by the illustrative embodiment of thepresent invention are set forth below.

If configured for a process, virtual loop-back address and/or virtual IPaddress hooking/modification may done in all of the followingintercepted methods:

Bind

Virtual loop-back: If the local address is the local-host loop-backaddress (127.0.0.1), it is replaced with a virtual loop-back address.

Virtual IP: If the local address is INADDR_ANY (0.0.0.0 all interfaces),it is replaced with a virtual IP address.

In most implementations, the (local) port is not checked but aconfiguration may be added to make the replacement contingent (or not)upon the port being non-zero.

Connect

Virtual loop-back: If the remote address is the local-host loop-backaddress, it is replaced with a virtual loop-back address.

Virtual IP: If no local address is specified in the Connect call(INADDR_ANY), then a force-Bind is done to the virtual IP address as thelocal address.

Although the (local) port is not usually checked, a configuration can beadded to make the replacement contingent (or not) upon the port beingnon-zero (Bind is not affected, since local port is zero). Bind is notforced (no explicit Bind) in case of loop-back address hooking, since,otherwise, the Winsock API returns an error “Host Unreachable”.

SendTo

Same as Connect.

Accept

Virtual loop-back: If the remote address is the virtual loop-backaddress for the process, it may be replaced with the local-hostloop-back address.

Virtual IP: No action.

Although the port is not usually checked, a configuration can be addedto make the replacement contingent (or not) upon the port beingnon-zero.

GetPeerName (for the remote socket)

Same as Accept.

GetSockName (for the local socket)

Virtual loop-back: Same as Accept and GetPeerName, however with respectto the local address.

Virtual IP: No action, i.e., same as Accept and GetPeerName.

The explorer.exe is hooked only in a session so that it affects onlylocal-host loop-back socket communications of explorer.exe withActiveSync. It does not affect communications with other processes aswell as remote socket communications of explorer.exe.

On the console special virtual IP address hooking is performed so thatINADDR_ANY is substituted with the local host loop-back address(127.0.0.1, which is the same as virtual loop-back address for SID=0) ifthe port is not 0 (zero).

Those skilled in the art will recognize that other hooking operationsmay be performed in addition to, or in place of, those outlined abovewithout departing from the scope of the present invention.

In addition to the previously depicted client-server architecture, theillustrative embodiments of the present invention allow for a“pass-through” architecture where the device in communication with aclient system that is connected over a network to a session running on aServer that is hosting a proxy client. FIG. 9A depicts a WinCE enabledPDA 500 connected to a client system 501, which accesses a proxy client520 executing in a session 505 hosted on a server 510. The client system501 may be an ICA client, which establishes a Control VD 503 and an I/ORedirector VD 504 with the Server 510. The proxy client 520 is connectedover a network to another session 560 running on a second Server 550.The proxy client 520 may be an ICA client which establishes a controlvirtual channel 530 and an I/O Redirector VD 540 with the second server550. An instance of application 570 executes within session 560. TheWinCE PDA 500 may be mapped into the second server 550 consistent withthe mechanisms outlined above.

Similarly, FIG. 9B shows an alternative architecture where both theproxy client and user session running an instance of the application aresupported by the same server. In FIG. 9B, the device 600 is incommunication with client system 601, which is connected over a networkto session 605 running on server 610. Session 605 runs a proxy client620 connected to a user session 630 running on the same server 610. Usersession 630 includes an instance of executing application 640. Device600 may be mapped into the user session 630 on server 610 via the proxyclient 620.

In another embodiment, FIG. 9C depicts a block diagram of an embodimentof the present invention implemented without the use of apresentation-level protocol supporting architecture. In FIG. 9C, thedevice 700 is in communication with client system 710 which is connectedover a network to server 720. Server 720 hosts an executing application740. Events occurring at the device 700 are re-directed to the server720 and the application 740. Those skilled in the art will recognizethat additional implementations and alternative architectures are alsopossible within the scope of the present invention.

In another embodiment, the invention includes interception of the deviceenumeration methods in a server session (via a hook DLL), and theirredirection (via an RPC call) to the Control VD 46 running in the serversession (See FIG. 1B). The redirected methods will enumerate onlydevices mapped in the respective session based on the information in theinternally maintained table of virtual device mappings, rather thandevices attached to the server console itself. Thus an applicationrunning in a server session is able to enumerate devices that havealready been mapped prior to launching of the application, i.e., devicesthe PnP event notifications of which the application has missed.

The present invention may be provided as one or more computer-readableprograms embodied on or in one or more articles of manufacture. Thearticle of manufacture may be a floppy disk, a hard disk, a compactdisc, a digital versatile disc, a flash memory card, a PROM, a RAM, aROM, or a magnetic tape. In general, the computer-readable programs maybe implemented in any programming language. Some examples of languagesthat can be used include C, C++, C#, or JAVA. The software programs maybe stored on or in one or more articles of manufacture as object code.

While the invention has been shown and described with reference tospecific preferred embodiments, it should be understood by those skilledin the art that various changes in form and detail may be made thereinwithout departing from the spirit and scope of the invention as definedby the following claims.

1. A method for handling plug-and-play events occurring at a client,said method comprising: detecting a first event notification of aplug-and-play event generated by a plug-and-play manager regarding adevice in communication with a client communicating with a server over anetwork using a presentation-level protocol, the first eventnotification comprising a globally unique ID for the device, a vendorID, a product ID, a device name, and an event type identifier;intercepting said first event notification at an operating systemabstraction layer prior to receipt of the notification by an applicationon the client; redirecting said first event notification to the serverfrom the client; creating an association between (i) a virtual device ina user session on the server and (ii) the device in communication withthe client; generating a second event notification of a plug-and-playevent in the user session for the virtual device, the second eventnotification including the created association; receiving a commanddirected to the virtual device from an application executing in the usersession on the server and in response to the second event notification;determining the command is directed to the device in communication withthe client, responsive to the created association; forwarding thecommand to the client; opening a virtual communication channel betweenthe device in communication with the client and the applicationexecuting in the user session on the server; and receiving at the clientvia the virtual communication channel, in response to the redirection ofthe first event notification, a command from the server, the commanddirected to said device.
 2. The method of claim 1 wherein redirectingsaid first event notification further comprises: generating a contextidentifier, said context identifier representing a virtual COM port;binding the context identifier to the event notification; andtransmitting the bound context identifier and event notification to theserver.
 3. The method of claim 1 wherein redirecting said first eventnotification includes redirecting said event notification via a virtualchannel.
 4. The method of claim 1, wherein receiving a command from theserver further comprises: receiving from a server a command including agenerated context identifier; identifying the device using the contextidentifier; and issuing a command to the identified device.
 5. Themethod of claim 1 wherein said first event notification is generated asa result of a device arrival.
 6. The method of claim 5 wherein saidcommand is an open command.
 7. The method of claim 1 wherein said firstevent notification is generated as a result of a device removal.
 8. Themethod of claim 7 wherein said command is a close command.
 9. The methodof claim 1 wherein the device in communication with the client uses oneof the USB (Universal Serial Bus) protocol, IEEE 1394 protocol,Bluetooth protocol, wi-fi protocol, wireless protocol, and infrared (IR)protocol to communicate with the client.
 10. The method of claim 1,further comprising: creating a server-unique name to identify the deviceconnected to the client that generated the event notification, saidserver unique name used in mapping the device to the server usersession.
 11. The method of claim 1 wherein redirecting furthercomprises: transmitting the first event notification to applicationscommunicating with the server.
 12. The method of claim 1 whereinredirecting further comprises: transmitting the first event notificationonly to applications communicating with the server which have previouslyregistered a callback for a type of event causing the first eventnotification.
 13. The method of claim 1 further comprising: emulating aplug-and-play event notification regarding a device in communicationwith the client.
 14. The method of claim 13 wherein the emulated eventnotification received from the client is received over a virtualchannel.
 15. The method of claim 1 wherein detecting a first eventnotification comprises: detecting a first event notification of aplug-and-play event regarding a device communicating with the client viaa USB connection on the client.
 16. A system for handling plug-and-playevents occurring at a client, said system comprising: a clientcommunicating with a server over a network using a presentation-levelprotocol; means for detecting a first event notification of aplug-and-play event generated by a plug-and-play (PnP) manager regardinga device in communication with the a client communicating with a serverover a network using a presentation-level protocol, the first eventnotification comprising a globally unique ID for the device, a vendorID, a product ID, a device name, and an event type identifier; means forintercepting said first event notification at an operating systemabstraction layer prior to receipt of the notification by an applicationon the client; means for redirecting said first event notification tothe server from the client; means for creating an association between(i) a virtual device in a user session on the server and (ii) the devicein communication with the client; means for generating a second eventnotification of a plug-and-play event in the user session for thevirtual device, the second event notification including the association;means for receiving a command directed to the virtual device from anapplication executing in the user session on the server and in responseto the second event notification; means for determining the command isdirected to the device in communication with the client, responsive tothe created association; means for forwarding the command to the client;means for opening a virtual communication channel between the device incommunication with the client and the application executing in the usersession on the server; and means for receiving at the client via thevirtual communication channel, in response to the redirection of thefirst event notification, a command from the server, the commanddirected to said device.